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In der folgenden Diskussion wird der Ausdruck "Kreditkarte" zu Zwecken der 
Anschaulichkeit verwendet; jedoch gelten die hier diskutierten Methoden und Grundlagen 
auch fur andere Arten von elektronischen Zahlungssystemen, wie etwa 
Kundenkreditkarten, automatisierte maschinenlesbare Kassenkarten und Telefonkarten. 

Seit jeher haben die Emittenden von Kreditkarten versucht, ihre Verluste durch Betrug zu 
begrenzen, indem die betriigerische Verwendung der Karte aufgezeigt wird, bevor der 
Karteninhaber eine verlorene oder gestohlene Karte gemeldet hat. 

Ein wirksames Modell zum Betrugsnachweis soUte hohe Fangraten bei niedriger 
Verhinderung rechtmafiiger Transaktionen im Echtzeitbetrieb ergeben. Es sollte sich 
verSndemden Betrugsmethoden und -muster anpassen konnen, und sollte eine integrierte 
LemfMhigkeit aufweisen, welche diese Anpassungsfahigkeit unterstutzt. 

Die vorveroffentlichte Druckschrift WO-A-8 906 398 beschreibt ein Element zur Analyse 
einer Transaktion mittels Datenverarbeitung: indem nur diejenigen Daten herausgezogen 
werden, die zur Analyse der Transaktion nutzlich sind; Signale geloscht werden, die einer 
Transaktion entsprechen, von der man meint, daB sie auf einen Satz vorbestinmiter Regeln 
pafit; gefiltert wird, damit nicht-signifikante Abwandlungen der zm analysierenden 
Transaktion beseitigt werden; imd die Signale in eine oder mehrere Klassen, gemaB einem 
vorbestimmten Kriterium, eingeteilt werden. Dieses Element ist zur Anwendung fur die 
Herausgabe von Zahlimgsautorisierungen an Kreditkartennutzer geeignet. 

Eine weitere Druckschrift, EP-A-0 418 144 beschreibt ein Verfahren zur Begrenzung der 
mit einer computergestfitzten Transaktion verbimdenen Risiken, indem die 
Transaktionsanfirage mit vorbestimmten statistischen Daten verglichen wird, die als 
representativ zur Risikobewertung einer nicht gemafien Verwendung erscheinen. Die 
statistischen Daten beschreiben die gemittelte Anzahl oder die Menge der wShrend der 
Abfolge von aufeinanderfolgenden Zeitabschnitten getatigten Transaktionen, und werden 
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abgeleitet, indem die Zeit in aufeinanderfolgende nicht gleiche Abschnitte eingeteilt wird, 
deren Dauem so gewahlt sind, dafi die Wahrscheinlichkeit einer getatigten Transaktion 
Oder der gemittelte Betrag fiir jeden einzelnen Zeitabschnitt im wesentlichen gleich sind. 

Aus der EP-0 669 032 sind ein auf einem Computer implementiertes 
Betrugsnachweisverfahren und eine entsprechende Hardware bekannt, welche 
Einrichtungen fiir Vorhersagemodelle einschlieBt. Aktuelle Transaktionsdaten werden 
empfangen und verarbeitet, was daim in einer Vielzahl von Ausgabewerten resultiert, die 
einen Trefferwert enthalten, der die Wahrscheinlichkeit fur eine betrugerische Transaktion 
darstellt. 

Dieses im Stand der Technik bekannte Verfahren erfordert mehrere Schritte, die vor den 
Verarbeitungsschritten fur die aktuellen Daten durchgefiihrt werden miissen, namlich: 

Erzeugen eines Benutzerprofils fiir jeden einzelnen einer Vielzahl von Benutzem 
aus einer Unmenge von Variablen bezuglich fruheren Transaktionen imd aus 
personlichen Benutzerdaten, die fur jeden Benutzer Werte aus einer Vielzahl von 
Benutzervariablen enthalten, wobei jedes Benutzerprofil ein Muster fur die 
Tatigkeitshistorie eines Benutzers beschreibt; 

Ableitung von Variablen, die nachgev^esenen fruheren Betrug betreffen, indem 
Daten fruherer Transaktionen vorverarbeitet werden, wobei diese Werte fiir eine 
Vielzahl von Transaktionsvariablen fur eine Vielzahl von fruheren Transaktionen 
beinhalten; 

Trainieren von Einrichtungen fur Vorhersagemodelle mit den Benutzerprofilen und 
mit den Variablen, die fruheren Betrug betreffen, um ein Vorhersagemodell zu 
erhalten; vmd 



Speichem des erhaltenen Vorhersagemodells im Computer. 

Dann erfolgt die Verarbeitung der aktuellen Daten, indem 

die aktuellen Transaktionsdaten fur eine aktuelle Transaktion eines Benutzers 
empfangen werden; 

die Benutzerdaten, die den Benutzer betreffen, empfangen werden; 

das mit dem Benutzer verbundene Benutzerprofil empfangen wird; 

die erhaltenen aktuellen Transaktionsdaten, Benutzerdaten und Benutzerprofil 
vorverarbeitet werden, um fur die aktuelle Transaktion Variablen bezuglich eines 
aktuellen Betruges abzuleiten; 

die Betrugswahrscheinlichkeit bei der aktuellen Transaktion bestimmt wird, indem 
das Vorhersagemodell auf die aktuellen betrugsbezogenen Variablen angewendet 
wird; und 

von den Einrichtungen ftir das Vorhersagemodell ein Ausgangssignal abgegeben 
wird, welches die Betrugswahrscheinlichkeit fur die aktuelle Transaktion anzeigt. 

Dieses System stiitzt sich auf ein neuronales Netz, um die Einrichtungen fur das 
Vorhersagemodell zu trainieren. Dieses Training soli hauptsachlich die Einrichtungen fur 
das Vorhersagemodell verandem, um die Verhinderung rechtmaUiger Transaktionen gering 
zu halten und die Leistung des Systems fur den Betrugsnachweis zu verbessem. 

Hierbei stutzt sich das System auf einen Satz von festen (aber veranderbaren) Werten, die 
verschiedene Aspekte der Transaktion darstellen. Diese Werte werden in der Verarbeitung 



unterschiedlich gewichtet und eine wichtige Funktion des auf dem neuronalen Netz 
basierenden Trainings ist die Veranderung dieser Gewichtung, was in grundlegender Weise 
eine "Lem"-Fahigkeit fur dieses System ergibt. Solche bekannten neuronalen Netze stellen 
eine Verkniipfung von „Neuronen" im Sinne einfacher mathematischer Ubertragungs- 
funktionen dar. Um hier eine „Lemfahigkeit" zu erzeugen, wird ein entsprechender 
Algorithmus eingesetzt - z.B. gemaB EP 0 669 032 zur Anpassung der „Gewichte" bei der 
Datenbewertung im neuronalen Netz. 

Bei alledem verwendet das System fur die Kombination der verschiedenen Parameter und 
Daten gewohnliche Logikalgorithmen und funktionelle Beziehungen, imi den Trefferwert 
zu erhalten. Es ftihrt fur jede aktuelle Transaktion eine Berechnung durch, die auf 
herkommlicher Logik basiert, betrachtet (spater) das Ergebnis und verandert, wenn 
notwendig, den Algorithmus. 

Es ist wiinschenswert, ein automatisiertes System zu schaffen, welches die verfugbaren 
Informationen z.B. tiber den Karteninhaber, Handler und GeschSfle verwendet, mxi 
Transaktionen zu prOfen xmd jene auszusondem, die wahrscheinlich betriigerisch sind, und 
dabei einen relativ hSheren Anteil an Betrugsfallen bei einer relativ niedrigen 
Verhinderung rechtmafiiger Transaktionen auffinden kann. Ein solches System soUte 
vorzugsweise noch fahig sein, mil einer groBen Zahl von voneinander abhangigen 
Variablen in einem schnellen Echtzeitbetrieb umzugehen, und soUte die Fahigkeit zur 
Riickentwicklung des zugrundeliegenden Systemmodells als neue Muster fur 
auftauchendes Betrugsverhalten aufweisen. 

DemgemaB betrifft die Erfindung ein in einem Computer implementiertes Verfahren zur 
Identifizierung und Bestimmvmg von betriigerischen Transaktionsdaten, gemaB den 
Merkmalen des Anspruchs 1. 



In mancher Hinsicht verwendet die Erfindung Merkmale, die aus der EP 0 669 032 bekannt 
sind. Auf die EP 0 669 032 wird deshalb in vollem Umfang Bezug genommen. 

Jedoch gibt as, wie aus der folgenden Beschreibung erkennbar, groBere Unterschiede 
zwdschen der Erfindung und diesem Stand der Technik, die sowohl in der grundlegenden 
Herangehensweise und der entsprechenden Grundstruktur, als auch in verschiedenen 
Einzelheiten der Datenerzeugung und -verarbeitung liegen. 

Ein wesentlicher Unterschied ergibt sich daraus, daB die vorliegende Erfindung kein 
Benutzerprofil als Teii des Vorhersagemodells verwendet. Statt dessen arbeitet die 
Erfindung mit einer Kombination von einerseits Expertenregeln und andererseits einer 
Analyse vorausgegangener Benutzungsvorgange des Zahlungsmittels, das fiir die aktuell zu 
bewertende Transaktion eingesetzt wird. 

Bei den Expertenregeln handelt es sich, vergleichbar dem eingangs genannten Stand der 
Technik, um eine auf Erfahrungswerten, i.e. der Analyse filiherer Mifibrauchsfalle, 
basierende Auswahl typischer Elemente einer individuellen Transaktion, die eine erhohte 
Gefahr eines MiBbrauchs anzeigen. Relevant sind erfindungsgemafi insbesondere die 
Herkunft des Zahlungsmittels (zum Beispiel der Karte), die Branche und die Person des 
EmpfSngers der zu autorisierenden Zahlung und der Betrag der Zahlung. 

Die Analyse vorausgegangener Benutzungsvorgange desselben Zahlungsmittels umfaBt 
vorzugsweise die jiingsten Vorgange, etwa die letzten funf bis zwanzig Transaktionen 
(konnte sich aber auch weiter zuriick erstrecken). 

Im Gegensatz zum Stand der Technik, zum Beispiel gemafi EP 0 669 032, verwendet die 
Erfindung vorzugsweise kein herkdnunliches neuronales Netz, kombiniert mit einem 
Lemalgorithmus. 
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Die Erfindung verwendet Fuzzy Logik zur Feststellung, ob eine bestimmte Transaktion als 



betrugerisch zu erachten ist. 

Im erfmdungsgemaB bevorzugten Entscheidungssystem werden sowohl die Expertenregeln 
als auch dem neuronalen Netz im Stand der Technik fiinktional entsprechenden Regeln fur 
die deskriptive Statistik als Fuzzy-Regeln abgespeichert, und unterscheiden sich damit 
nicht in der Berechnungsart, jedoch in der Gewinnungsart. 

Das Expertenwissen ist direkt als Fuzzy-Regeln formuliert. Diese definieren fur jede 
Transfliionsart ein Limit, das der (benutzerspezifischen) , Jlisikobereitschafl" entspricht. 



Die Information aus der Benutzungshistorie des Zahlungsmittels wird mit Hilfe eines 
, J^euroFuzzy-Modtils" ebenfalls in Fuzzy-Regeln transformiert. Das NeuroFuzzy Modul 
verwendet eine Modifikation desjenigen Trainingsalgorithmus, der auch bei den meisten 
neuronalen Netzen verwendet wird, namlich den Error Backpropagation Algorithmus, der 
weithin in der Literatur beschrieben ist. Da in dieser Weise die Information aus den 
Ve^angenheitsdaten (also das was zum Beispiel gemSB EP 0 669 032 in den Gewichten 
des trainierten neuronalen Netzes abgespeichert wird) als lesbare und 
interpretier-Zmodifizierbare Fuzzy-Regeln zur Verfugung steht, sind diese in jeder Weise 
erganz-, verifizier- und erweiterbar. Hinsichtlich der Eingangs- und Ausgangsdaten 
kdnnen die "neuronal" erzeugten Fuzzy-Regeln die gleichen GroBen verwenden wie die 
Expertenregeln. 

Die „neuronal" erzeugten Fuzzy-Regeln beruhen vorzugsweise auf einer Analyse 
vorausgegangener Transaktionen hinsichtlich solcher Faktoren wie dem durchschnittlichen 
Betrag der Transaktion, dem Anteil von Barauszahlungen, dem Anteil von 
AuslandseinsStzen, von Reisekostennutzungen, dem frOheren Auftreten von 
VerdachtsfMlen usw. und hinsichtlich „dynamischer" Kriterien wie etwa der aktuellen 
AusschSpfving des Limits der betrofifenen Kreditkarte. Das Ergebnis dieser Analyse wird 




auch als ,yZeitreihe" bezeichnet. Dieses Regelsystem ermittelt so fur jede Transaktion ein 
dynamisches Risiko in Form eines „Bonus" bzw. „Malus". 

Die Erfindung gestattet so die Verschmelzung statistischer Modelle mit Expertenwissen. 
Statt, wie beim Stand der Technik, fur jeden Vorgang einfach eine Betrugswahrschein- 
lichkeit auszurechnen, wird das ftir jede Transaktionsart definierte Limit gleitend mit dem 
dynamischen Risiko („Bonus" oder „Malus") der spezifischen aktuellen Transaktion zu 
einem (gleitenden) Transaktionsiimit kombiniert. 

Dies ermoglicht imterschiedliche, differenzierte Behandlungen „auffalliger" Transaktionen, 
Z.B. die sofortige Sperre oder statt dessen die Verweisimg zur individuellen Oberprufung, 
Z.B. durch einen Sachbearbeiter. 

Im Stand der Technik wird eine Transaktion, die oberhalb der berechneten Risikoschwelle 
liegt, normaierweise gesperrt; der Stand der Technik kennt grundsatzlich nur Freigabe oder 
Sperre als Ergebnis der Uberprufung. Die Erfindung ermoglicht statt dessen abgestufte 
Reaktionen; beispielsweise kann ein Verdachtsfall generiert werden (und damit in die 
,,Zeitreihe" ftir diese Kreditkarte eingehen, die ftir zukunflige Transaktionen herangezogen 
wird), obwohl die aktuelle Transaktion autorisiert wird. Bei stSrkerem Verdacht wiirde eine 
NachprOfung (referral) der aktuellen Transaktion (vor deren eventuellen Freigabe) 
ausgel5st; bei noch stSrkerem Verdacht wiirde die Transaktion verweigert (decline). 

Wesentliche Unterschiede zum Stand der Technik ergeben sich auch hinsichtlich der 
Modellbildung, also der Generierung und Erkennung von Mifibrauchsmustem 
(Fraudmustem). 

Der Stand der Technik basiert auf „passiver Datengewinnung". Mit anderen Worten, 
ausschlieBlich bereits vorhandene Vergangenheitsdaten werden zur Modellbildung 
herangezogen. Das bedeutet, um im Modell uberhaupt ein Fraudmuster erkennen zu 
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kSnnen, muB (a) bereits genug Zeit verstrichen sein, damit die Fraudmeldungen bereits 
zuruckgekommen sind (meist erst, nachdem die Kunden ihren Auszug gelesen haben), (b) 
mussen genug Falle fur ein sicheres Training vorhanden sein (nur so funktioniert ein 
neuronales Netz / es gibt Fraudfalle, die sehr selten sind, aber einen hohen Einzelschaden 
ausmachen, die sind so nur sehr schwer im Modell zu erfassen, © erst nach einem 
auiwendigen manuellen Retraining ist eine Immunisierung des Autorisierungsbetriebes 
uberhaupt m5giich. 

Hingegen ist die Datengewinnung erfindungsgemaB „aktiv". Tauchen die ersten 
Verdachtsmomente eines neuen Fraudmusters auf, so werden Regeln definiert, die sofort 
eine Nachrecherchierung genau dieser Falle durch aktive Kontaktierung der Kunden 
auslosen. So stehen im Idealfall innerhalb weniger Stunden viele gesicherte Daten dariiber 
zur Verfugung, ob hier tatsachlich ein neues Fraudmuster aufgetaucht ist, und wie es sich 
von anderen Mustem abgrenzt. Diese Analyse laBt sich (egal mit welchem Verfahren) 
namlich erst durchftihren, wenn genug gesicherte Daten vorhanden sind. 

Die Methodik der Modell-Erstellung im Stand der Technik fiihrt dazu, daB die Erfahrung 
menschlicher Analysten zu wenig genutzt werden kann und Erwartungen iiber zukOnftige 
Fraudmuster nicht Eingang finden k5nnen. Im Stand der Technik bildet das neuronale Netz 
praktisch eine „black box" festgelegter, starrer Kriterien, die nur noch „automatisch", also 
als Ergebnis wiederum vorher festgelegter Algorithmen, hinsichtlich der „Gewichte" 
modifiziert werden. Soweit uberhaupt Expertenregeln zusammen mit neuronalen Netzen 
eingesetzt werden, laufen neuronales Netz und Expertenregeln unabhangig nebeneinander. 
Durch den NeuroFuzzy-Ansatz ist das mit Daten trainierte prSdiktive Modell keine black 
box mehr, sondem wird in Form von Fuzzy-Regeln erzeugt. Diese sind direkt von 
Experten interpretierbar und modifizierbar. 



Die erfmdungsgemafien gleitenden Transaktionslimits erlauben eine wirkungsvoUe 
Kombination von .Jiard facts" und „soft facts". Dies ermfiglicht eine Modellierung der 
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„soft" und ,4iard" facts in konsistenter und kooperativer Weise. Bei dem „black-box"- 
Ansatz im Stand der Technik ist das nicht wichtig, denn dort findet keine wissensbasierte 
Modellierung statt. Bei der Erfindung, die es ermSglicht und vorzugsweise auch vorsieht, 
daB automatische Modellbildung und menschliche Expertise im laufenden Betrieb 
kombiniert werden, ist dies sehr relevant. 

Im folgenden wird die Erfindung an einem Ausfuhrungsbeispiel naher erlautert, welches 
gegenwartig besonders bevorzugte Ausgestaltungen des erfindungsgemaBen Grundprinzips 
umfafit. 

Das Ausfuhrungsbeispiel betrifft ein Autorisierungssystem fur Kreditkarten-Transaktionen 
imd damit eine Gnmdkonstellation ahnlich der im eingangs behandelten Stand der Technik. 
Aus einem vorhandenen Netzwerk, das Nutzungsstellen ftir die im System benutzbaren 
Kreditkarten umfaBt, kommen Autorisierungsanfragen, die in Echtzeit bearbeitet und 
beantwortet werden mussen. 

Die Bearbeitung der Autorisierungsanfragen erfolgt im erfindungsgemaB ausgestalteten 
Autorisierungssystem, das schematisch in den Figuren 1 bis 4 gezeigt ist. 

Das System umfaBt im Ausfuhrungsbeispiel mehrere Rechner, kann aber natiirlich auch auf 
einem Zentralrechner oder mittels eines Rechner-Netzwerks realisiert werden. 

Im Beispiel umfaBt das System einen „Tandem"-Rechner mit einer Datenbank A, einen 
„SGr'-Server (SQL-Server) mit einer Datenbank B und ein „Hostsystem" mit einer 
Datenbank C. 

Auf dem Tandem-Rechner ist eine Software implementiert, die fur Datenubergaben, Data 
Preprocessing (Kriterien-Ableitung), Zeitreihenberechnungen imd -aktualisierungen etc. 
dient, v^e sp^ter noch deutlich werden wird. Weiterhin ist auf dem Tandem-Rechner die 



erfindvingsgemaBe Entscheidungslogik implementiert, die Fuzzy-Expertenregeln und 
Neuio-Fuzzy-Modelle umfaBt und die Entscheidung Uber die Autorisierungsanfragen trifft. 
Die auf dem Tandem-Rechner implementierte Software wird im folgenden 
zusammenfassend als „NeuroFvizzy Inferenzmaschine" (NFI) bezeichnet. 

Der SGI-Server dient, gegebenenfalls zusammen mit einer entsprechenden Zahl von PC- 
Clients, insbesondere zur Implementiening der Software fur den ..Investigation Workflow" 
(IW) fUr die Nachbearbeitung von VerdachtsMlen, und fiir das ..Online Data Mining 
Module" (ODMM), wie spater noch erlautert werden vnrd. 

Das Hostsystem enthSlt und erhalt die wesentlichen historischen wie aktuellen Daten zu 
Zahlungsmittel und Nutzer, die fiir die Bearbeitung der Autorisierungsanfragen benStigt 
werden. 

Figur 1 zeigt den grunds^tzlichen Informationsaustausch wie folgt: 

Das Autorisienuigssystem erlangt Daten (1) fiir ein Cardholder File aus der Datenbank [C] 
des Hostsystems. Bei einer Anderung der Daten des Cardholder Files werden nur die fiir 
die Autorisierung relevanten Daten einer Kartennummer auf das Autorisierungssystem 
uberspieh. Ereignisse wie Kartensperrungen mit einer hohen Prioritat werden sofort 
ubertragen, andere mit einer kleineren Prioritat erst wesentlich spater. Der Datentransfer 
(Update) erfolgt stundlich. 

Der SGI-Server erhalt (2) Uber das bestehende Netzwerk vom Tandem- 
Autorisierungsrechner die Autorisierungsanfragen. versehen mit der von NFI ausgelSsten 
Aktion (diese besteht aus: Fallwichtigkeit. Fallklasse, Fallschwelle, Referralentscheidung, 
Risko-Score, Limit und Action Code) sowie die aktuelle Zeitreiheninformation. (Die 
hierfiir erforderlichen Echtzeitanforderungen liegen im Bereich von Minuten. Die 
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Gesamtinformation zu einer Autorisierungsanfrage wird von der NFI zu einer Nachricht 
komprimiert, die dann an den SGI-Server ubertragen wird.) 

Weiter erhait der SGI-Server vom Hostsystem alle Postinginformationen, 
MiBbrauchsinformationen und gegebenenfalls Karteninhaberstammdaten, die nicht aus der 
Cardholder File extrahiert werden konnen (3). Die Datenbank des SGI-Servers [B] 
speichert diese Daten je nach Speicherausbau so lange wie erforderlich. Der SGI-Server 
beherbergt die Serverkomponente sei es des Supervisory Workflov^ (ODMM) als auch des 
Investigation Workflow (IW). 

Figur 2 zeigt den DatenfluB bei vermuteten bzw. erkannten Mifibrauchsfallen. 

Der Investigation Workflow (I W) (6) dient der Bearbeitung der erkannten und vermuteten 
Fraudfalle, insbesondere durch Mitarbeiter (Call-Center). 

Im Call-Center wird festgestellt, ob es sich bei den vermuteten Mifibrauchsfallen um 
tatsachliche Mifibrauchsfalle handelt. Es erfolgt eine entsprechende Mitteilung (7) an den 
SGI-Server. 

Neben dieser ersten Hauptaufgabe erfullt der SGI-Server noch eine weitere Hauptaufgabe: 

Die Datenbank des SGI-Servers speichert die fur das Entdecken neuer Fraudmuster 
erforderlichen Daten und bereitet diese fur eine Analyse durch das Online Data Mining 
Modul (ODMM) auf. Hierftir werden die mifibrauchsrelevanten Daten in der Datenbank 
[B] zwischengespeichert. Im Fraud Supervisory Center werden dann mittels dieser 
Informationen (4) neue Fraudregeln definiert und die vorhandenen Fraudregeln werden 
kontinuierlich auf ihre Wirksamkeit hin uberpriift. 
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Die entsprechend modifizierten Fraudregeln in Fonn einer Datei werden vom Fraud 
Supervisory Center auf den Autorisierungsrechner ubertragen (5). Hierzu wird vom PC aus 
die Datei auf den SGI-Server gebracht. Auf dem SGI-Server wird ein automatischer Job 
installiert, der erkennt, wenn der Timestamp der Datei sich geandert hat, und in diesem 
Falle einen Austausch der Datei auf der Tandem vomimmt, als auch der NFI mitteilt, dafi 
es diese Datei neu einlesen mufi. 

Es ergeben sich somit insgesamt zwei Workflows (Figur 4): 

1 . Der Supervisory Workflow ODMM paBt die Entscheidungsstrategie des 
Praventionssystems kontinuierlich an die sich andemden MiBbrauchsmuster an. 

2. Der Investigation Workflow IW kontroUiert die Entscheidimgen des Praventions- 
systems durch Einzelbearbeitung der gemeldeten und vermuteten Mifibrauchsfille. 

Beide Workflows sind indirekt iiber die (nuttlere) operative EDV-Ebene verbunden. Wird 
im Supervisory Workflow die Entscheidungsstrategie modifiziert, so werden vom 
Praventionssystem andere Referrals generiert, die im Investigation Workflow 
nachrecherchiert werden. 

Nicht vom Praventionssystem rechtzeitig erkannter MiBbrauch sowie falschlicher 
MiBbiauchsverdacht wird vom Investigation Workflow verifiziert und in der Datenbank 
des SGI-Servers abgelegt. Hierauf greift das Online Data Mining Modul (ODMM) zu und 
schlagt den Fraudexperten im Fraud Supervisory Center entsprechende Modifikationen der 
Entscheidimgsstrategie vor. 

Die gesamte Berechnung, also der FluB der Fuzzy-lnferenz durch das Regelwerk, sowie die 
gesamte Profilbildung und -initialisierung, wird von der NFI selbst iibemommen; es ist 
keine exteme Steuerung erforderlich. Die Schnittstelle enthalt weitere Fvmktionen zur 
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Initialisierung und Konfigiiration der Entscheidungslogik (diese Funktionen mussen einmal 
beim Laden des Praventionsmoduls aufgerufen werden), die aber nicht pro 
Autorisierungsanfrage aufgerufen werden mussen. 

Die SQL-Datenbank des Autorisierungsrechners (Cardholder File) wird um ein Feld 
"Zeitreihe" erganzt. Dieses Feld speichert die letzten Autorisierungsanfragen zu dieser 
Kartennununer (Nutzungsprofil) in komprimierter Form ab. Wenn eine 
Autorisierungsanfrage in das System kommt, wird der komplette Datensatz der Karte aus 
der Datenbank geladen. Hier muB nun zusatzlich noch das Binarobjekt "Zeitreihe" aus der 
Datenbank geladen und dem NFI zugefuhrt werden. Das Binarobjekt Kartennutzungsprofil 
wird in einer stark komprimierten Form erzeugt, so dafi es in Form eines String in der 
SQL-Datenbank eflfizient fiir den EchtzeitzugrifiF gespeichert werden kann. Zuisatzliche 
Rechenzeit durch das Auslesen und Wiedereinspeichem des Kartenprofils bei jeder 
Autorisierungsanfrage wird keinen spiirbaren Rechenaufsvand bedingen, da der Datensatz 
einer Karte sowieso bei jeder Autorisierungsanfrage ausgelesen wird. Nach der 
Entscheidung aktualisiert das NFI die Zeitreihe um die jetzt gerade eingegangene 
Autorisierung. Genau wie die durch die Autorisierung aktualisierten Limits muB auch die 
aktualisierte Zeitreihe wieder in die Datenbank zuriickgeschrieben werden. 

Weiterhin wird die Cardholder File erganzt um zwei Datumsfelder, je eines fur "kein 
Referral bis" (Dieses Feld wird bei einem positiv beantworteten Referral gesetzt, um 
sicherzustellen, daB nicht sofort nach einer positiven ID des Karteninhabers dieser bei der 
nachsten Transaktion direkt wieder einen Referral erhalt) und eines fur "Kurzreferral bis" 
(bei akutem Verdacht wird dieses Datum gesetzt, um bis zu diesem Datum bei jeder 
Autorisierungsanfrage einen Referral zwangsweise zu erzeugen.). Diese Felder werden 
Uber das Autorisierungssystem gesetzt oder zuriickgesetzt. Die Daten werden vom ^ 
Autorisierungssystem an die NFI ubergeben, die NFI wertet die Daten aus und entscheide^, 
ob ein Referral oder Decline, und gegebenenfalls ein Fall generiert werden soli. Da die 
NFI gegebenenfalls auch mandantenabhangige Regeln enthalt, muB die NFI den 
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Mandanten aus der Kartenummer erkennen. (Mandant ist z.B. der Kunde der 
Processingfirma, fur welchen das Fraudprocessing durchgefuhrt wird) 

Die Entwicklungskomponente ist Bestandteil des Supervisory Workflow und eine 
grafische Entwicklungs- und Analysesofhvare, die auf Windows/NT Workstations 
(Clients) installiert wird. Hierbei kann es sich um vorhandene Rechner handeln, der auch 
ftir andere Aufgaben genutzt wird. oder es kann ein eigener Rechner bereitgestellt werden. 

Von der Entwicklungssoftware aus kann der Entwickler das Fuzzy-Entscheidungssystem 
der Tandem modifizieren. Hierbei wird in keinem Fall der laufende AutorisierungsprozeB 
gestoppt, gestort oder verlangsamt. 

Werden neue Betrugsprofile bekannt, so erlaubt die Entwicklungskomponente, diese durch 
Modifikation bekannter und Definition neuer Regeln zu berUcksichtigen. Dabei werden 
diese neuen Regehi und modifizierten Regeln in die NFI ubertragen, wo sich die neuen 
Regehi augenblicklich auf das Autorisierungsverhalten auswirken. 

AUe Autorisierungsanfragen werden von der Tandem uber TCP/IP an den SGI-Server 
ubergeben. Der SGI-Server legt fur jede Autorisienmgsanfrage einen neuen Record an und 
fUllt diesen mit alien erforderlichen Information. 

Liegt die Fallwichtigkeit einer Autorisienmgsanfrage Uber der Fallschwelle, so legt der 
SGI-Server zusStzlich einen Fall an. Ein Fall besteht aus einem Eintrag in der Falltabelle 
und den hierzu gehSrigen Untertabellen. 



ZusammengefaBt: 



Jede von der Tandem eingehende Message beschreibt eine Autorisierungsanfrage. 
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Ftir jede Autorisierungsanfrage wird ein Record £ingelegt. 

Die Fallerzeugung ist von den Referrals unabhangig, d.h. es kann ein Fall erzeugt werden, 
ohne daB ein Referral erzeugt wurde und es kann ein Referral erzeugt werden ohne daB ein 
Fall erzeugt vsdrd. 

Diese Schnittstelle ist auf Seiten der SGI-Server erstellt. Die Erzeugung der 
entsprechenden Eintrage in den Tabellen des SGI-Servers ebenfalls. 

Zur Nachbearbeitung der mdglichen BetrugsfSlle und Referrals dient der Investigation 
Workflow. Hierbei wird fur die Fallsortierung die von der NFI ermittelte Fallwichtigkeit 
zugrundegelegt. Ob oder ob nicht fur diese Autorisierungsanfrage ein Referral generiert 
wurde, ist ftir die Generierung eines Falles unerheblich. Die Fallgenerierung arbeitet mit 
einer eigenen Entscheidungslogik, die auch Regeln abweichend von den Betrugsregeln 
enthalten kann. Hierdurch lassen sich Praventionsstrategien sozusagen "erstmal im 
Trockenen" ausprobieren. Damit konnen im Investigation Workflow auch solche Falle 
nachverfolgt werden, bei denen der Verdacht nicht flir eine Referralgenerierung ausgereicht 
hat. 

Komprimierte Soeicherung der Autorisierungshistorie ("Zeitreihe"^ 

Die NFI arbeitet mit neuronalen Modellen, die auf der Analyse firuherer Transaktionen 
beruhen. 

Problem einer solchen Analyse ist, daB wahrend der Bearbeitung einer Autorisierungs- 
anfrage keine Abfrage und Analyse vergangener Transaktionen in Echtzeit moglich ist. 
Daher muB die NFI eine Kurzhistorie in einem Ringpuffer zwischenspeichem. (Ein 
Ringpuffer ist ein Speicher mit einer festen Anzahl von Platzen, die hintereinander 
geschaltet sind. Jedes neu gespeicherte Objekt wird "vome" in den Ringpuffer 
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hineingeschoben, was alle bereits im Ringpuffer befindUchen Objekte je eine Position 
weiterschiebt. Das Objekt auf dem letzten Platz fdllt dabei voliig aus dem Ringpuffer 
heraus.) Besonders wichtig ist hier, dafi diese Zeitreihe so wenig Speicherplatz wie 
mOglich erfordert (jedes Byte pro Karte ergibt einen Nettospeicherplatzbedarf von ungefahr 
7 Megabyte in der Datenbank des Autorisierungsrechners), und so schnell und effizient wie 
mSgiich gelesen und geschrieben werden kann. 

Aus diesem Grunde basiert die Zeitreihenbildung auf einem Algorithmus, der diesen 
Ringpuffer so erzeugt und aktualisiert, daB dieser effizient zu speichem und zu berechnen 
ist. Zur Speicherung wird eine komprimierte Speicherung im umgewandelten 
Ganzzahlformat verwendet. 

Die Zeitreiheninformation stellt dabei z.B. eine verdichtete Historie der letzten 15 
Autorisierungsanfragen dar, die eine Berechnung von dynamischen Kriterien 
(AusschSpfung, Panik, Tankstellennutzung,...) ermSglicht. Die Zeitreiheninformation 
erlaubt zudem die Ermittlung von aggregierten GrSBen wie: Durchschnittiiche 
EinkaufshShe, Anteil Cashing, Anteil Ausland, Anteil Reisekostennutzung, wann wurde 
zum letzten Mai ein Referral ausgesprochen und wann wurde zum letzten Mai ein Referral 
beantwortet. 

Da die Zeiti^iheninformation 15 mal (ftir jede Autorisierungsanfrage im Ringpuffer) 
abgespeichert werden muB, ist hier eine Komprimierung der Information besonders 
wichtig. 

Da in der Datenbank das Profil als Binarobjekt (Stiingformat) abgespeichert wird, kSnnen 
die einzelnen Teilinformationen jeder Transaktion im Ringpuffer als Ganzzahlen beliebiger 
Bitlange codiert werden. Es wurde allerdings eine sinnvoUe Aufteilung einzelner 
BiUangen auf die Bytes des Stringformats gewahlt, damit die Berechnung und 
Aktualisierung der Profile nicht zu rechenaufwendig wird. Hierdurch ist nicht immer "auf 
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Bit genau" die kiirzestmogliche Speicherform gewahlt, sondem es ergibt sich ein 
KompromiB aus Speicherplatzbedarfminimierung und Rechenperformancemaximierung. 

Zu den gespeicherten Feldem im einzelnen: 

- Datum 

Die Abspeichenmg des Datums im Minutenfomiat emioglicht das einfache Berechnen von 
Zeitdifferenzen im Ganzzahlarithmetik einer 16-bit Zahl (mit 16-Bit Minutenauflosung 
lassen sich maximal 45 Tage darstellen, was fur die Berechnung von Zeitdifferenzen im 
Profil ausreicht)* 

Die bei Subtraktionen solcher Minutenwerte resultierenden 16-Bit Werte fur die 
Zeitdifferenzen werden direkt ohne rechenaufwendige Umskalierungen als EingangsgrOBen 
der NFI verwendet. 

Mit der maximalen Speicherlange des Minutendatums nach Stichtag von 24 Bit mufi 
allerdings ein Reset der Profilinformationen alle 31 Jahre erfolgen. 

1st dieser Eintrag "Datum" gleich "0", so bedeutet das, daB dieser Eintrag im Ringpuflfer 
noch nicht verwendet ist. 

- Betrag 

MuB durch 10 dividiert werden, um den Euro-Betrag zu ergeben. Hierdurch ergibt sich 
eine optimierte Ausschopfung des 20 bit Zahlenbereiches, Betragsabweichungen unter 
Euro 0,10 sind ftir die MiBbrauchspravention vmerheblich, und der maximale darstellbare 
Betrag von ttber Euro 100.000,00 ist auch ausreichend. Angefiragte Werte fiber Euro 
100.000,00 werden auf Euro 100.000,00 im Ringpufifer abgeschnitten. 
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-MCC 

Enthait den Branchencodes des Vertragspartners, der die Autorisierung angefragt hat. 
ICA 

Beschreibt alle Issues anhand ihrer ICA-Nummem. 
Country Code 

Fiir die Zeitreihenbetrachtungen reicht der Country Code zur Herkunftsbestinunung aus. 
Dieser ist maximal dreistellig, daher reichen 10 bit zur Darstellung aus (nach MC Quick 
Reference Booklet, Oktober 97). 

-POS 

Nimmt die 5 mSglichen POS Entry Modes auf. Zwar wUrden 3 bit ausreichen, um die 5 
moglichen POS Entry Modes darzustellen, doch bietet die Darstellung in 4 bit rechnerische 
Vorteile. 

-Status 

Status beschreibt beispielsweise, ob das Verfallsdatum falsch war, oder ob ein CVC 
Problem aufgetreten ist, etc.. (Auf der Magnetkarte ist die Kartennummer um einen 
dreistelligen Code (CVC-1) erweitert. Dieser dreistellige Code ist nicht errechenbar. 
Damit ist uber diese Prufung eine recht gute Identifikation einer echten Karte mOglich.) 
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Hierdurch ist gewahrleistet, daB auch nichtautorisierte Anfragen in dem Profil 
berucksichtigt werden kSnnen. 

Fraud Supervisory Workflow 

Der Fraud Supervisory Workflow umfaBt alle Werkzeuge, die verwendet werden, um die 
Entscheidungslogik zu kontroUieren und zu warten. Im einzelnen sind dies die Module: 

- Online Data Mining Modul 

Zur systematischen Erkennung neuer MiBbrauchsmuster, sowie zur kontinuierlichen 
Priifiing der Treffsicherheit aktuell definierter Entscheidungsregeln. 

- Entscheidungslogik 

In diesem Modul werden die Entscheidungskomponenten entwickelt, iiberwacht und 
gesteuert. 

- Analyse-NFI 

Die Analyse-NFI dient dem Test neuer Entscheidungslogiken an Vergangenheitsszenarien. 
Online Data Mining Modul (ODMM^ 

Das Online Data Mining Modul besteht sowohl aus einer Serverkomponente auf dem SQL- 
Server als auch aus einer Clientkomponente auf PC. Die Clientkomponente arbeitet mit 
dem Server uber Pass-Through Queries und verkniipfte Tabellen zusammen. 
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Das ODMM arbeitet mit den Tabellen, in denen die fiir die Analysen erforderlichen 
Autorisierungsanfragen und Falle abgelegt sind. 

Der ODMM Client erhSlt folgende Informationen zu jeder Transaktion: 

- Kartennummer (Zusammen mit Datum und Zeit der Transaktion dient diese Information 
der eindeutigen Zuordnung jeder Transaktion (Schlussel). Da zu einer Transaktion 
mehrere Ereignisse (zum Beispiel mehrere Autorisierungsanfragen, MiBbrauchs- 
meldungen, beantwortete Referrals, etc.) gehoren konnen, die zu unterschiedlichen Zeiten 
stattfmden konnen, wird hier immer das friiheste Datum eingesetzt. Dies entspricht 

der Logik, daB die zu dieser Transaktion gehorenden Ereignisse sich alle auf den 
ersten Zahlungswunsch beziehen, der im System bekannt geworden ist. 

- Datum und Zeit der Transaktion 

- Betrag in Eitto 

- Typ der Transaktion (autorisierte oder nichtautorisierte Transaktion; bei nicht- 
autorisierten Transaktionen liegt beispielsweise keine Autorisierungsanfrage vor, 
jedoch kann beispielsweise ein Posting und eine MiBbrauchsmeldung vorliegen) 

- MiBbrauch (ist MiBbrauch aufgetreten?) 

- Referral (ist ein Referral generiert worden, wenn ja, wie beantwortet) 

- Informationen aus der Autorisierungsanfrage oder dem Posting (Branchencode, 
Country Code Herkunft, POS Entry) 

- Zufallszahl (Auswahl einer Stichprobenmenge) 
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Die Tabellen, die diese Informationen liefem, werden von den ODMM Clients iiber Pass 
Through Queries abgefragt. 

Der Server ordnet im Nachhinein eintreffende Mifibrauchsmeldungen zu bereits in der 
Tabelle TRX eingetragenen Transaktionen zu. Ebenfalls werden die Ergebnisse fur die 
statistische Komponente aktualisiert. 

- Rasterfahndung 

Die Rasterfahndung lauft als Pass-Through Query auf dem Server und generiert eine 
Tabelle mit Regeln, die aktuell nicht aktiviert sind und von denen es sinnvoU ware, sie 
aufzunehmen. Jeder Regel ist eine Mifibrauchssumme zugeordnet, die im 
Untersuchungszeitraum hatte verhindert werden konnen, wenn diese Regel aktiv gewesen 
ware. Um diese Aussage zu verifizieren, enthalt jede Regel auch das Verhaltnis falschlich 
zu gerechtfertigt abgelehnter Autorisierungsanfragen (F/P-Rate), die Anzahl 
gerechtfertigter und die Anzahl nicht gerechtfertigter Referrals, welche die Beurteilung zur 
Aufhahme oder Ablehnung der Regel ermSglichen. Es ist moglich, die Regeln vorweg 
durch Angabe eines bestimmten MiBbrauchsbetrags und F/P-Rate zu filtem. Bei kleineren 
Summen oder hQheren F/P-Raten werden die gefundenen Regeln ausgeblendet. Auch die 
Gewichtung zwischen der MiBbrauchssumme und der F/P-Rate kann bei der Sortierung 
eingestellt werden. Damit kann bei jeder Rasterfahndung emeut festgelegt werden, wie 
bedeutend jede der beiden Grofien fur die Untersuchung sein soil. 

- Regeloptimierung 

Die negativ beantworteten Referrals, die keinen MiBbrauch bestatigen konnten, dienen der 
Empfehlung zur Deaktivierung von Regeln als Grundlage. Wird ein Referral negativ 
beantwortet, so wird der dazugehorige Datensatz nicht mehr als MiBbrauch, sondem als 
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gute Transaktion in die Analyse einfliefien. Sollte sich dann herausstellen, dafi die Kegel 
nicht genug Milibrauch verhindert hat und zu viele gute Transaktionen verhindert hat, so 
wird sie zur Deaktivierung vorgeschlagen. Auch in dieser Analyse kann die Gewichtung 
zwdschen der MiBbrauchssvunme und der F/P-Rate eingestellt werden. Damit kann auch 
hier bei jeder Rasterfahndung emeut festgelegt werden, wie bedeutend jede der beiden 
GroBen fur die Untersuchung sein soil. 

Entscheidungslogik 

Der Zugriff auf die Entscheidungslogik erfolgt uber den Fraud Supervisory Workflow: 

Der Block "Fraud Supervisory Workflow" stellt die PC-Netzwerke im Stab-SI dar. Diese 
verwalten beliebig viele Entscheidungslogiken, sei es zur Archivierung als auch als 
ZwischenstSnde der Entwicklung. (Die eigentlichen Daten far die Entscheidungslogiken 
werden zentral auf dem SGI-Server gespeichert, so daB alle Fraud- Analysten hierauf 
Zugriff haben. Der Zugriff auf diese Entscheidungslogiken erfolgt durch die PC mit der 
"Fraud Supervisory Workflow" Software.) Jede der Entscheidungslogiken besteht aus den 
drei Komponenten Listen, Zeitreihe und Regeln. Durch Druck auf die jeweilige Taste 
oflhen sich die entsprechenden Editoren fur die Komponenten. 

Im Produktivbetrieb lauft immer die Entscheidungslogik "Betrieb". Durch Druck der 
Taste [iibertragen] wird die aktuell im PC entwickelte Entscheidungslogik "Betrieb" auf 
die Tandem iibertragen und aktiviert. 

Auf dem SGI-Server laufen beide Entscheidungslogiken fur die Szenarienanalyse. Durch 
Druck der Taste [iibertragen] wird die aktuell im PC entwickelte Entscheidungslogik 
"Test" auf die SGI-Server iibertragen und aktiviert. 
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Vorgehensweise bei der Entwicklung 

Die grundsatzliche Vorgehensweise bei der Entwicklung von Entscheidungslogiken ist die 
folgende. Auf dem Autorisierungsrechner lauft die Entscheidungslogik "Betrieb". Durch 
Driicken der Taste [ubertragen] wird die Entscheidungslogik "Test" mit der 
Entscheidungslogik "Betrieb" iiberschrieben. (Hierbei handelt es sich nicht um ein 
physikalisches Uberschreiben von der Tandem auf die SGI-Server. Die SGI-Server 
verfugen ebenfalls uber eine Kopie der Entscheidungslogik, wodurch das Uberschreiben 
direkt auf den SGI-Servem ausgefuhrt wird.) 

Hierdurch kann nun die Entscheidungslogik "Test" auf dem PC modifiziert werden und mit 
Hilfe der Analyse-NFI erfolgt der Test von Modifikationen durch direkten Vergleich des 
"Test"-Systems mit dem "Betriebs" -System. 

Sind die an der Entscheidimgslogik "Test" durchgefuhrten Modifikationen erfolgreich, so 
wird durch Driicken der Taste [ubertragen] die Entscheidungslogik "Test" mit der 
Entscheidungslogik "Betrieb" uberschrieben. Nachdem die neue Entscheidungslogik in 
Betrieb gegangen ist, fangt die Vorgehensweise emeut an. 

Jede neue Transaktion wird von der NFI-Maschine mit einer Fallwiirdigkeitsbeurteilung 
versehen. Ein Hilfsmodul kennzeichnet eine Transaktion als Fall, wenn sie ein 
Fallkriterium erftiUt (MCC, ICA, CNT, POS, Betragsklasse, Fallwiirdigkeit). 

Wie weit die Historie der Transaktionen imd Postings eines Vorgangs zuruckgeht, kann 
wahlweise bestimmt werden. Als sinnvoU wird ein Zeitraum von 4-6 Wochen erachtet. 

GehSrt eine Transaktion zu einer Kategorie aller moglichen FSUe, so wird ein neuer Record 
in der Investigation Workflow eigenen Tabelle angelegt. Dieser Record enthalt folgende 
Einzelinformationen: 
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- Kartennummer 

. Transaktionsdaten (Datum/Uhrzeit, MCC, CNT, ICA, POS, Betrag,) 

- Fallstatus (ist der Fall neu oder vAirde er abgeschlossen) 

- Fallwichtigkeit (die Fallwichtigkeit F W stellt den NFI-Score dar) 

- Fallklasse (Die Fallklasse gibt an, warum eine Transaktion zu einem Nachbearbeitungs- 
fall geworden ist bzw. zu welcher Kategorie die Transaktion gehort. Die Kennung 
beinhaltet folglich Angaben uber MCC, ICA, CNT, POS, Betragsklasse, FW.) 

- Benutzemame 

- Wiedervorlagedatum 

- Close-Status (Der Close-Status eines Falls gibt Auskunft uber das Ergebnis der Bear- 
beitung nach SchlieBen des Falls und kann folgende Information enthalten: "Kein Betrug" 
Oder "kein Betrug geschatzt", "Betrugsbestatigung unmoglich" oder "Betrug" oder 
"Betrug geschatzt".) 

Die Kartennummer ist das Bindeglied (Zeiger) zu den vergangenen Transaktionen mit 
derselben Kartennummer auf dem DBMS des SGI-Servers. Zusammen mit den 
Stammdaten der Kartennummer sind alle Daten fur den Fraud Investigation Workflow 
voUstandig. 

EineanesgraBen der NFI 

Die NFI wird uber ein TokenprotokoU in den Ablauf der Autorisierung integriert. Hieraus 
entnimmt die NFI alle EingangsgroBen sowie die Zeitreihe als Binardatenobjekt (String). 

Als Sonderform der Autorisierungen hat die NFI die Nachrichten uber eine Referralsperre 
oder ein Referral_bis zu interpretieren. 
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Referral^bis: Der Parameter Referral _bis (Kurzreferral) wird bei MiBbrauchsverdacht zur 
Verhinderung von Genehmigungen benutzt. Es wird manuell mittels einer Autorisierung 
aktiviert. 

Die NFI speichert das Referral_bis Datum im Kartenprofil ab und iiberpriift bei der 
Autorisierung, ob das Transaktionsdatum kleiner dem Referral_bis Datum ist. 1st dies der 
Fall, wird immer ein Referral von der NFI generiert. 

Das Referrai_bis Parameter wird zur Analyse und Rekonstruktion als Bestandteil des 
Transaktionsdatensatzes uber die TCP/IP-Schnittstelle zum SGI-Rechner ubertragen. 

Referralsperre: Die Referralsperre wird dazu benutzt, nach einer positiven Identifikation 
oder nach Sichtung der vergangenen Transaktionen die weitere Auslosung von Referrals zu 
unterbinden. Die Referralsperre kann die Zustande "giiltig" oder "nicht gultig" annehmen. 
Ist sie "gultig", so wird ein vorher eingestellter Parameter, der einen festen Offset vom 
aktuellen Transaktionsdatum (zum Beispiel Transaktionsdatum + 3 Tage) angibt, aktiviert. 
Die Referralsperre ist immer in Form des Datums gegeben, bis zu dem sie gehen soli. Es 
kann ja nur zum aktuellen Zeitpunkt bestimmt werden, ob die Sperre damit gultig ist oder 
nicht. 

Die Referralsperre kann einerseits vom Investigation Workflow aus aktiviert werden. 
Andererseits kann die Referralsperre auch indirekt vom Genehmigungsservice ausgelost 
werden, wenn nach einem Referral eine positive Identitats-Uberpriifung stattgefunden hat. 
Nach einer positiven IdentitatsUberpnifung wird vom Genehmigungsdienst eine 
Transaktion ausgelost, die in der NFI verarbeitet wird. Die NFI schreibt die aktuelle 
Referralsperre in die Cardholder File auf dem Autorisierungsrechner. 
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Der Fall, dafi sowohl eine Referralsperre als auch das Referral_bis Datum giiltig ist, muB 
vermieden werden. Daher wird beim Setzen eines Wertes (zum Beispiel Referral_bis) der 
jeweils andere gelSscht (zum Beispiel Referralsperre). 

Tnteme Au spangserSBen 

Liegen alle EingangsgroBen vor. die von der NFI verwendet werden. so erzeugt die NFI 
intern 6 AusgangsgroBen: 

1. Limit 

2. RiskScore 

3. Fallwichtigkeit 
4: Fallschwelle 

5. Fallbegrundung 

6. Decline 

Hierbei stellt Limit direkt das transaktionsindividuelle Limit fUr die aktuelle 
Autorisierungsanfrage dar. Dieses transaktionsindividuelle Limit wird durch den 
RiskScore als Malus vermindert ("gleitendes Transaktionslimit"). 

Die NFI entscheidet nun durch einfachen Vergleich, ob ein Referral erzeugt werden soil 
Oder nicht. Ein Referral wird immer dann erzeugt, wenn der zur Autorisierung angefragte 
Betrag uber dem transaktionsindividuellen Limit liegt. Durch die Gr5Ben "Referralsperre" 
und "Referrai_bis" kann die Entscheidung der NFI modifiziert werden. 

Die weiteren drei GrSBen stellen die Entscheidung der NFI bezUglich der Fallgenerierung 
dar. Die Fallwichtigkeit stellt dar, in zu welchem Grade die aktuelle Autorisierungsanfrage 
als Fall erzeugt werden soil. Liegt dieser Wert tiber der Fallschwelle, so wird fur die 
Autorisierung ein Fall erzeugt. ZusStzlich wird als Begrundung der Entscheidung, einen 
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Fall aus dieser Autorisierungsnachricht zu generieren, ein Text "Fallklasse" erzeugt, der die 
Verdachtsart mit Worten beschreibt. Diese Beschreibung wird von dem Mitarbeitem des 
Investigation Workflow genutzt, um eine gezielte Ermittlungsarbeit durchfiihren zu 
konnen. 

Diese AusgangsgroBen der NFI werden direkt mit der gesamten Information zu der 
Autorisierung an die Autorisierungsanfrage ubertragen. Die bestehende Software zur 
Autorisierung bearbeitet diese Information dann weiter, 

Nach der Berechnung der NFI libergibt die NFI an das System die aktualisierte Zeitreihe. 
Das System speichert diese in der Cardholder File, um sie bei der nachsten 
Autorisierungsanfrage dieser Kartennummer wieder an die NFI zu iibergeben. 

Die eigentlichen Entscheidungsregeln der NFI werden in einer Datei auf dem 
Autorisierungsrechner abgelegt. Diese Datei wird von dem Entwicklungswerkzeug auf 
dem PC erzeugt. 

Im folgenden wird die Entscheidungslogik naher erlautert. Dabei werden folgende 
Abktirzungen verwendet: 



Tabelle 1 


AvailBal 


— 

Noch verfugbarer Betrag auf der Karte 




in Euro 


Betrag 


Betrag, der zur Autorisierung angefragt 




wird (in Euro) 


BranchenCode 


Einzelne Branchencodes 
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Branchenklasse 


T<ri5iQQ<* Her Rranche zu der der VP eehort 


CoimtryCode 


T 3riH<»rrnHf» Aii^ der Autorisieruncsnachricht 


CurrencyCode 


Wahrungscode aus Autorisierungsnachricht 


GAC 1 


Action Code aus Listendefinition 


ICA^BIN 1 


Herkunft der Transaktion 


Inanspruchnahme 


Noch zu definieren! 


Kartenalter 


Alter der Karte in Tagen gemessen an der 
Zeit, die seit "gultig ab neu" vergangen ist 


Kartenlimit 


Limit der Karte in Euro 


KT Ranse 


Zueehoriekeit der Kartennummer zu Ranges, die 
als Liste definiert sind 


letzte Antwort 


Wie lange ist der letzte beantwortete 
Referral/Callme her? 


letzte GAA 


• 

Zeit, die seit der letzten GAA-Abhebung 

1 vergaiigcii Id I 




letzter Referral 


Wi^» 1 Jin OP der letzte Referral/Callme her? 


\landan.t 


j Identifikation des Mandanten 


Merchant_ID 


1 Merchant ID aus Listendefinition 


Panikfaktor 


ist noch zu definieren! 


POS_Eingabe 


Eingabeart der Autorisierungsanfrage 


TerminalJD 


1 Terminal ID aus Listendefinition 



ZOl 



Eingangsvariable des Zahlers XXXX 
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Die folgende Abbildung zeigt die Struktvir fur dieses Fuzzysystem mit Eingangsinterfaces, 
Regelblocken und Ausgangsinterfaces. Die Verbindungslinien symbolisieren hierbei den 
Datenflufi. 



AUcn»iyungcr»ocr<ic« 





Betfag 




ICA.BIN 




CounHyCode 




CureneyCa.. 




StdnchenC... 






do: 


POS.Etnga...;- 




Mcfchvl.lO 




Tenninal.lO 




6AC 






Kdrtenalet 


IVY 


Mtfidart 


ro/ 






ICarteriirnt 


1 ^ r 





Apgregieftg Krierign « js 
prV" LetetcGAAl 



IV ITT'n 




Herktmn s afwtys e 

BtanchenC... | 
BrdnchenKL.. 
CountryCode 
CunencyCo... 
ICA^BIN 
MeichanljO . 
POS.Einga.-. 



MAX 



Special Merchard Watch 



MIN 



BisncHenC... 
ICA.BIN 



RegeLimit 



Mercnart Type Watch . 



. Rasterfahndung 



MIN 



BianchenCL^ RegeLinit 



BranchenC. 
ICA.BIN 
POS.Einga., 




RegeLimit 




MAX 



Cashingregein 




MIN 


BidnchenKL.. 
RegeQJmil 


GansLimit 




MAX 



Rfrt erralgcnef ler uTig 
^ Ga^^L^mi^ "^^1 
RttkoScore ^.Sfl|t\| 



Peclnef egein nach Btedcfats 



1 MIN 


W-Range 
MefChantJO 


Oec&ne 


TenninalJO p 


MAX 



AnwendungsregeJn 



Avs3Bd 1 


MIN 


Betrag 




InanspnicK.... 


Profi 


ICartenalef 






Mandant 




Panadaklor 


8SUM 






1 MiN 


BranehenI 


^ RisacoSeore 




1 MAX 


»alyse) 






Oftcfinegcncfiefvig 



Rege^n fur Faaerxeuguig 

"gAC I MIN 

Panklaktof 

PtoR 

Z01 FaBCiasse 

Z02 FalwichtifiMl 
Z03 

204 

205 MAX 



FaOgorvsrienxig 



Falwch6gke> SSSlIliJ 

fSsSwSTI*"] 



FaBCIasse 



Abbildung I: Struktur des Fuzzy Logic-Systems 
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Linguistische Variablen dienen in einem Fuzzysystem dazu, die Werte kontinuierlicher 
GroCen durch sprachliche Begriffe zu beschreiben. Die moglichen Werte einer 
linguistischen Variablen sind keine Zahlen, sondem sprachliche Begriffe, auch Terme 
genannt. 

Fiir alle Eingangs-, Ausgangs- und ZwischengrSBen des Fuzzy-Systems werden 
linguistische Variablen definiert. Die ZugehSrigkeitsfunktionen der Terme sind durch 
StUtzstellen, die sogenannten Definitionspunkte, eindeutig festgelegt. 

Die folgende Tabelle listet alle linguistischen Variablen zusammen mit den Termnamen 
auf. 
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Tabelle 2: Lineuistische Variablen 



AvailBal 


niedrig, mittel, hoch 


Betrag 


niedri? mittel &roRer 1 000 hnrh 


BranchenCode 


FlugAUg, Kaufhaus, Pelze, Teppiche, Schallplatten, Nacht- 
lokale, Waffensprot, Juwelier, Foto, Leder, alle Banking, 

T4^0tp1 Alley !i]}f^^^r\AC^C^ A^nccao^ AntrkAIIrr PiinT7rtf»i'7tf»it 

nvLci^^i^, oiic^^crxviv^v^, ivictddcigc, /\ULO/\iig, FluirrcizciL 


Branchenklasse 


Clothing, contrctd_services, mail_order, misc_store, 
nicht531 1, pers_services, retail, services, transportation, 
utilities, -cashing 


CountryCode 


Agypten, Brasilien, Equador, Hongkong, Indonesien, Israel, 
Kolumbien, Malaisia, Marokko, Mexiko, Singapur, Thailand, 
Ttirkei, Venezuela, Kanada 


CurrencyCode 


f_franc, drachme, forinth, gulden, i_lira, peseta, pfund 


GAC 


bad_cvc 1 


ICA_BIN 


Visa_quer, mexiko spezial, -mexiko spezial | 


Inanspruchnahme 


niedrig, mittel, hoch 


Kartenalter 


sehr_neu, neu, alt 


Kartenlimit 


niedrig, mittel, hoch 


KI^Range 


kein__range, fraud_nz, alle_anderen 


letzte Antwort 


gerade_erst, v_lang_her 


letzte GAA 


gerade_erst, mittel, lang_her 
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letzter Referral 


gerade_erst, v Jang_her 


Mandant 


kein_mandant, gzs, aiiplus 


Merchant_ID 


wempe 

— " ' 


Panikfaktor 


niedrig, mittel, hoch 


POS_Eingabe 


unbekannt, unbek__o_manuell, manuell, gelesen, electr_ 

COiiiiiicrcC, gClCacli ^wpiuxt 


TerminaMD 


KTiniin ^iigoiu 11 


ZOl 


inenr_ais_vicr 


Z02 


niejir_ais__vier 


Z03 


incnr_aib_v icr 


Z04 


nieiir_ais^v ici 


Z05 


VYt^VlT* die 171^1* 

lliciir__<iis V ici 


Z06 


UlCill d-Aij viwi 11 


TSfl 


IllCIli <11 J V Awl 


ZOo 


mpVir als vier 




mehr als vier 


ZIO 


mehr__als_vier 


Zll 


mehr_als_vier 


Z12 


meh_r_als_vier 


Zeitreihenlange 


hoch 


Decline 


kein_decline, decline 
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rallklasse 


counterteit, hongkong, cvc_queue, ungam, watchlist, | 
juweliere 1 


Fallwichtigkeit 


unverdachtig, mittel, verdachtig 


Limit 


_0,_100,_250,_500,_1000,_2500,_7500 1 


RisikoScore 


unverdachtig, mittel, verdSchtig | 


Profil 


unverdachtig, riskant | 


Regel-Limit 


_0,_1 00,_250,_500,_ 1 000,_2500,_7500 1 



Die Eigenschaften der Basisvariablen sind in der folgenden Tabelle aufgeiistet. 



Tabelle 3: Basisvariablen 



Variableimame 


Min 


Max 


Default 


Einheit 


AvailBal 


0 


20000 


0 


Euro 


Betrag 


0 


20000 


0 


Euro 


BranchenCode 


0 


9999 


0 


MCC 


Branchenklasse 


0 


32 


0 


Codewert_Liste 


CountryCode 


0 


999 


0 


CC_Schlassel 


CurrencyCode 


0 


999 


0 


CC_Schlussel 


GAC 


0 


32 


0 


Codewert_Liste 


ICA_BIN 


0 


32 


0 


Codewert_Liste 


Inanspruch- 


0 


100 


0 


Prozent 
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1 nahme 










1 Kartenalter 


0 


100 


0 


Tage 


Kartenlimit 


0 


20000 


0 


Euro 


KI_Range 


0 


32 


0 


Codewert_Liste 


letzte Antwort 


0 


45 


45 


Tage 


letzte GAA 


0 


45 


0 


Tage 


letzter Referral 


0 


45 


45 


Tage 


Mandant 


0 


32 


0 


Codewert_Liste 


Merchant_ID 


0 


32 


0 


CodewertListe 


Panikfaktor 


0 


100 


0 


Prozent 


POSJEingabe 


0 


32 


0 


POS_Entry_ 
Mode 




Terminal_ID 


0 


32 


0 


Codewert_Liste 


ZOl 


0 


32 


0 


Anzahl 


Z02 


0 


32 


0 


Anzahl 


Z03 


0 


32 


0 


Anzahl 1 


Z04 


0 


32 


A 

u 


/\IlZ.aiil 11 


Z05 


0 


32 


0 


Anzahl 1 


Z06 


0 


32 


0 


Anzahl 


Z07 


0 


32 


0 


Anzahl 


Z08 


0 


32 


0 


Anzahl 
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Z09 


0 


32 


0 


Anzahl 


ZIO 


0 


32 


0 


Anzahl 


Izii 


0 


32 


0 


Anzahl 


j Z12 


0 


32 


0 


Anzahl 


Zeitreihenlange 


0 


32 


0 


AutoriAnfragen 


Decline 


0 


1 


0 




Fallklasse 


0 


32 


0 


Codewert_Liste 


Fallschwelle 


0 


1000 


750 


Schwelle 


Fallwichtigkeit 


0 


1000 


0 


Promille 


Limit 


0 


30000 


0 


Euro 


RisikoScore 


0 


1000 


0 


Promille 



Der Defaultwert wird von der Ausgangsvariablen angenommen, wenn flir diese Variable 
keine Regel feuert. Fur die Defuzzifizierung konnen unterschiedliche Methoden eingesetzt 
werden, die entweder das "plausibelste Resultat" oder den "besten" KompromiB liefem. 

Zu den kompromlBbildenden Verfahren gehOren: 
CoM (Center of Maximum) 
CoA (Center of Area) 

CoA BSUM, eine Variante fur effiziente VLSI-Implementierangen 

Das "plausibelste Resultat" liefem: 
MoM (Mean of Maximum) 

MoM BSUM, eine Variante fur effiziente VLSI-Implementierungen 
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Die folgende Tabelle listet alle mit einem Interface verknupften Variablen auf, sowie die 
entsprechende Fuzzifizierungs- bzw. Defuzzifiziervmgsmethode. 

Tabelle 4: Interfaces 



Variablenname 


Typ 


Fuzzifizierung/ 
Defuzzifizierung 






Berechne MBF 


ocirag 




Berechne MBF 






Berechne MBF 


R 1*51 n f*Vi tf^n W 1 51 Q Qf* 




Berechne MBF 


i CountryCode 


Eingang 


Berechne MBF 


CurrencyCode 


Eingang 


Berechne MBF 


GAC 


Eingang 


Berechne MBF 


ICA^BIN 


Eingang 


Berechne MBF 


Inanspruchnahme 


Eingang 


Berechne MBF 


Kartenalter 


Eingang 


Berechne MBF 


Kartenlimit 


Eingang 


Berechne MBF 


KI^Range 


Eingang 


Berechne MBF 


letzte Antwort 


Eingang 


Berechne MBF 


letzte GAA 


Eingang 


Berechne MBF 
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letzter Referral 


Eingang 


Berechne MBF 


Mandant 


Eingang 


Berechne MBF 


Merchant_ID 


Eingang 


Berechne MBF 


Panikfaktor 


Eingang 


Berechne MBF | 


POS^Eingabe 


Eingang 


Berechne MBF I 


TerminalJD 


Eingang 


Berechne MBF 


ZOl 


Eingang 


Berechne MBF | 


Z02 


Eingang 


Berechne MBF 


Z03 


Eingang 


Berechne MBF 


Z04 


Eingang 


Berechne MBF 


Z05 


Eingang 


Berechne MBF | 


Z06 


Eingang 


Berechne MBF i 


Z07 


Eingang 


Berechne MBF 


Z08 


Eingang 


Berechne MBF 


Z09 


Eingang 


Berechne MBF 


ZIO 


Eingang 


Berechne MBF 


Zll 


Eingang 


Berechne MBF 


Z12 


Eingang 


Berechne MBF 


Zeitreihenlange 


Eingang 


Berechne MBF 


Decline 


Ausgang 


MoM 


Fallklasse 


Ausgang 


MoM 1 
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Fallschwelle 


Ausgang 


Vorgabe | 


Fallwichtigkeit 


Ausgang 


CoM 1 


Limit 


Ausgang 


MoM 


RisikoScore 


Ausgang 


COM 



Regelblocke 

Das Verhalten des Reglers in den verschiedenen ProzeBsituationen wird durch die 
Regelblocke festgelegt. Jeder einzelne Regelblock enthalt Regeln fur einen festen Satz von 
Eingangs- und Ausgangsvariablen. 

Der "wenn"-Teil der Regeln beschreibt dabei die Situation, in der die Regel gelten soil, der 
"dann"-Teil die Reaktion hierauf. Durch den "Degree of Support" (DoS) kann hierbei den 
einzelnen Regeln ein unterschiedliches Gewicht gegeben werden. 

Zur Auswertung der Regeln >vird zuerst der "wenn"-Teil berechnet. Hierbei konnen 
verschiedene Verfahren eingesetzt werden, die durch den Operatortyp des Regelblocks 
festgelegt sind. Der Operator kann vom Typ MIN-MAX, MIN-AVG oder GAMMA sein. 
Das Verhalten des Operators wird zusatzlich durch eine Parametrisierung beeinflufit. 

Beispielsweise: 



MIN-MAX, mit dem Parameterwert 0 
MIN-MAX, mit dem Parameterwert 1 
GAMMA, mit dem Parameterwert 0 



= Minimum-Operator (MIN). 
= Maximum-Operator (MAX). 
= Produkt-Operator (PROD). 
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Der Minimum-Operator ist die Verallgemeinerung des boolschen "xmd" und der 
Maximum-Operator ist die Verallgemeinerung des boolschen "oder". 

Die Ergebnisse der einzelnen Regeln werden bei der anschlieBenden Fuzzy-Composition 
zu GesamtschluBfolgerungen zusammengefaBt. Die BSUM-Methode betrachtet hierbei 
alleflir einen Zustand feuemden Regeln, wahrend die MAX-Methode nur dominante 
Regeln beriicksichtigt. 
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ANSPRUCHE 



1. Auf einem Rechner realisiertes Verfahren zum Identifizieren und Ermitteln 
betriigerischer Transaktionsdaten in einem rechnergesteuerten Transaktionsverarbeitungs- 
system mit einem Vorhersagemodell zum Empfangen aktueller Transaktionsdaten, 
Verarbeiten der aktuellen Transaktionsdaten und Ausgeben wenigstens eines 
Ausgangswertes, der eine Wahrscheinlichkeit einer betrugerischen Transaktion wiedergibt, 
bei dem auf Grundlage gespeicherter Daten zu 

- einer Zeitreihenanalyse friiherer Transaktionen beziiglich des gleichen 
Zahlungsmittels bzw. Benutzers imd 

- Expertenregeln hinsichtlich bei betrugerischen Transaktionen statistisch 
signifikant gehSuft auftretenden Parametem, insbesondere bes^uglich der Herkimft des 
Zahlungsmittels/Benutzers, der Branche und der Person des durch die Transaktion 
Begtinstigten, sowie Hohe bzw. Wert der Transeiktion, mittels des Vorhersagemodells die 
Bewertimg hinsichtlich des Risikos erfolgt, daB die aktuelle Transaktion betriigerisch ist, 
und ein entsprechender Ausgangswert erzeugt wird, 

dadurch gekennzeichnet, daB das Pradiktionsmodell ein im wesentHchen auf den 
Expertenregeln basierendes, fur die Art der Transaktion, spezifisches Limit mit einem im 
wesentlichen auf der Zeitreihenanalyse basierenden ftir die aktuelle Transaktion 
spezifischen Wert kombiniert, um den Ausgangswert zu erzeugen, 

wobei die Kombination gleitend erfolgt, so dafi je nach StSrke des 
MiBbrauchsverdachts verschiedene Ausgangswerte erzeugt werden konnen, die zur 
Auslosung imterschiedlicher Reaktionen auf der aktuellen Transaktionsanfrage benutzt 
werden konnen. 

2. Verfahren nach Anspruch 1, bei dem die Zeitreihenanalyse in Form von Fuzzy- 
Logik-Regeln implementiert ist. 
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